llllinilllNlllUllllllllilll 

US 20020152215A1 

(19) United States 

(12) Patent Application Publication («» Pub. No,: US 2002/0152215 Al 

Clark et al. (43) Pub. Date: Oct 17, 2002 



(54) DISTRIBUTING ELECTRONIC BOOKS 
OVER A COMPUTER NETWORK 



(76) Inventors: George Philip Clark, Lutz, FL (US); 

Jeflrey Walter Crawford, Penfield, NY 
(US); Edward John Marino, Nashville, 
TN (US); Laura rice Holmes Brewster, 
Brentwood, TN (US) 



Correspondence Address: 
Patent Group 
Foley Hoag & Eliot LLP 
One Post Office Square 
Boston, MA 02109-2170 (US) 



(21) AppLNo.: 

(22) Filed: 



09/963,928 
Sep. 26, 2001 



Related U.S. Application Data 

(60) Provisional application No. 60/243,259, filed on Oct. 
25, 2000. 

Publication Classification 

(51) Int. CI. 7 G06F 17/60; G06F 7/00 

(52) U.S. CI 707/10; 705/26 



(57) 



ABSTRACT 



In general, in one aspect, the disclosure describes a method 
of processing content for distribution over a computer 
network. The method includes receiving submitted elec- 
tronic content, accessing identification of at least one of a set 
of more than one electronic book digital rights management 
(DRM) systems, and automatically generating an electronic 
book from the received electronic content for distribution in 
accordance with the identified electronic book digital rights 
management system(s). 
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DISTRIBUTING ELECTRONIC BOOKS OVER A 
COMPUTER NETWORK 

REFERENCE TO RELATED APPLICATIONS 

[0001] This application claims priority from co-pending 
U.S. provisional application Serial No. 60/243,259, filed 
Oct. 25, 2000, entitled "Systems and Methods for Digital 
Content Submission, Management and Distribution", which 
is incorporated by reference in its entirety herein. 

[0002] This application relates to U.S. patent application 
Ser. No. 09/906,428, entitled "Processing Content For Elec- 
tronic Distribution using a Digital Rights Management Sys- 
tem", filed on Jul. 16, 2001; U.S. patent application Ser. No. 
09/906,443, entitled "Electronic Content Distribution", filed 
on Jul. 16, 2001; and U.S. patent application Ser. No. 
09/906,203, entitled "Fulfilling a Request for an Electronic 
Book", field on Jul. 16, 2001. 

BACKGROUND 

[0003] Much like an ordinary printed book, electronic 
books ("eBooks") can be used to present text and pictures to 
readers. Instead of ink and paper, however, an electronic 
book is a collection of digital data that software, known as 
an electronic book reader, can interpret and present on a 
display. A variety of devices run electronic book reader 
software such as personal computers, handheld personal 
digital assistants (PDAs), cellular phones with displays, and 
so forth. 

[0004] Electronic books can offer a variety of features not 
traditionally associated with print books. For example, 
instead of text and pictures, an electronic book may also 
store data used to present sound such as music and speech. 
Further, instead of still pictures, an electronic book can also 
present animated images. Additionally, by transmitting 
eBook data over a computer network, eBooks can be deliv- 
ered to remote locations almost instantaneously. 

[0005] Unfortunately, in many ways, copying data is 
easier than photocopying pages of a book. To protect the 
rights of those trying to sell or otherwise limit access to 
electronic books from pirating, companies have developed a 
wide variety of digital rights management (DRM) systems. 
For example, Microsoft currently offers a "Digital Asset 
Server" that guards against unauthorized user access to 
Microsoft Reader eBooks. Similarly, Adobe offers a number 
of different DRM solutions such as Adobe Content Server. 

[0006] DRM solutions differ significantly in their 
approaches to the task of controlling access to eBooks. For 
the purposes of illustration, however, FIGS. 1 and 2 depict 
a typical DRM scheme. As shown in FIG. 1, a client 104, 
such as a PDA or personal computer, can send a message 
108 to a server 100 over a network 102 such as the Internet. 
The message 108 requests access to an eBook and includes 
credentials of the requester such as the identity of the device 
104 and/or reader software making the request. The server 
100 uses the credentials to scramble (i.e., encrypt) the data 
of the requested eBook. As shown in FIG. 2, the server 100 
then sends the scrambled data 106 to the requesting client 
104. Using its own credentials, the client 104 reader can 
unscramble (i.e., decrypt) and present the eBook to a user. If 
a device other than the client 104 receives the eBook data, 
it should lack the proper credentials needed to perform the 
unscrambling. 



SUMMARY 

[0007] In general, in one aspect, the disclosure describes a 
method of distributing electronic books over a computer 
network. The method includes transmitting user interface 
instructions to a publisher's network client in response to an 
HTTP (HyperText Transfer Protocol) request received from 
the client. The user interface instructions provide a web- 
page form that enables the publisher to identify electronic 
content and corresponding metadata. The metadata includes 
designation of at least one electronic book digital rights 
management system from at least two supported digital 
rights management schemes from different unaffiliated ven- 
dors. The metadata also including hard printing information. 

[0008] After receiving the identified electronic content 
and metadata from the network client, the method includes 
automatically generating an electronic book from the 
received electronic content corresponding to the identified 
electronic book digital rights management system. The 
method also includes storing the metadata with metadata 
associated with other received electronic content, selecting 
metadata from the stored metadata that corresponds to 
electronic content authorized for a retailer, and storing at 
least a portion of the selected metadata for transmission to 
the retailer over the network in accordance with formatting 
information received from the retailer. The method further 
includes receiving a request for the electronic book from a 
network client in response to a user's selection of the 
corresponding electronic content from a user interface pro- 
vided by the retailer, determining whether to distribute the 
electronic book to the network client by applying one or 
more business rules to the request, and distributing the 
electronic book to the network client in accordance with the 
electronic book's electronic book digital rights management 
system. 

BRIEF DESCRIPTION OF TOE DRAWINGS 

[0009] FIGS. 1-2 are diagrams illustrating an example of 
an electronic book digital rights management system. 

[0010] FIG. 3 is a diagram illustrating different features a 
server can provide to publishers, retailers, and consumers. 

[0011] FIG, 4 is a diagram illustrating content submission 
over a network. 

[0012] FIGS. 5-11 are screenshots of a user interface 
presented to a publisher. 

[0013] FIG. 12 is a flow-chart of a process for automati- 
cally processing received content. 

[0014] FIG. 13 is a diagram illustrating catalog distribu- 
tion to a retailer. 

[0015] FIG. 14 is a diagram illustrating catalog genera- 
tion. 

[0016] FIG. 15 is a flow-chart of a process for generating 
a catalog. 

[0017] FIGS. 16-18 are diagrams illustrating fulfillment of 
a request for an electronic book. 

[0018] FIG. 19 is a flow-chart of a process for fulfilling a 
request for an electronic book. 
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DETAILED DESCRIPTION 
[0019] I. Introduction 

[0020] FIG. 3 shows a server 210 that can provide a 
variety of features that can ease tasks involved in electronic 
and printed book distribution. To illustrate some of these 
features, FIG. 3 shows a sample sequence that begins with 
submission 222 of a title from a publisher 204 and ends with 
the title's distribution 228 to a consumer 208. 

[0021] As shown in FIG. 3, a publisher client 204 can 
submit content 222 for a title to the server 210 over a 
network 202 such as the Internet. Such content can include 
data specifying text, graphics, and even multimedia such as 
music or video. 

[0022] The publisher client 204 can also submit informa- 
tion about the content known as "metadata". The metadata 
can include identifier information such as the ISBN, UPC or 
DOI of the work; pricing information for one or more 
markets in which the work may be sold; bibliographic 
information such as the author and title of the work; distri- 
bution information such as identification of territories where 
selling the work is authorized, retailers authorized to sell the 
work, and/or identification of one or more digital rights 
management systems for protecting the work when distrib- 
uted electronically; and/or manufacturing information, such 
as a printing and/or binding specifications, for use in the 
preparation of hard copies of the work. 

[0023] The server 210 can automatically prepare the con- 
tent for distribution. For example, for electronic distribution, 
the server 210 can automatically format eBook information 
for distribution of the title in accordance with one or more 
selected digital rights management systems. For hard copy 
manufacturing and distribution, the server 210 can automati- 
cally prepare the content for printing, for example, by 
extracting a cover page for color printing and generating 
bit -map images of book pages. 

[0024] In addition to the behind-the-scenes work of pre- 
paring content for distribution, the server 210 may also 
provide information to retailers 206, such as Amazon.com 
and BarnesandNoble.com, to help display and sell titles. For 
example, the server 210 may use collected metadata to 
generate a customized catalog file 224 of content authorized 
for sale by a retailer 206. The catalog file 224 can include 
author names, a summary, and/or selected images (e.g., book 
cover thumbnails). A retailer 206 can use the catalog file 224 
to automatically update its web-site's offerings. For 
example, Amazon.com can automatically generate web- 
pages for newly available titles identified in the catalog file 
224. 

[0025] The server 210 can also insulate retailer 206 from 
the technical details of title distribution across multiple 
digital rights management systems. For example, after a 
consumer 208 selects an eBook from the retailer's 206 
web-site 226, the server 210 can distribute 228 the title to a 
consumer 208 in accordance with a digital rights manage- 
ment system selected for the content. This frees the retailer 
206 from the burden of setting-up, integrating, and main- 
taining a host of different digital rights management systems 
that different eBook formats may require. Similarly, for a 
hard copy, the server 210 can offer a "print-on-demand" 
service that produces a hard copy of a title for delivery to a 
consumer or retailer. 



[0026] Though FIG. 3 depicts a single publisher 204, 
retailer 206, and consumer 208, the server 210 can support 
a very large number of each of these entities. Further, while 
the server 210 may constitute a single computer, the server 
210 may instead represent a logical collection of devices. 

[0027] While the description above highlights a few fea- 
tures offered by the server 210, the server 210 can also offer 
a wide array of other services such as providing reports (e.g. 
usage reports, title demand reports, retailer invoices, and 
publisher compensation) to retailers 206 and publishers 204. 
A server 210 may offer all of the features described above or 
only support a limited subset of these services. These and 
other features are described in greater detail below. 

[0028] II. Content Submission 

[0029] FIG. 4 illustrates a scheme that enables a publisher 
204 to securely transmit content 230 over a network 202 to 
a server 210 for subsequent electronic distribution and/or 
hard copy printing. As shown, in addition to content 230, the 
server 210 can also receive metadata 232 corresponding to 
the content. Such metadata can include bibliographic infor- 
mation about the content, "print-on-demand" information 
used to generate a hard copy of the content, and/or distri- 
bution information such as identification of retailers autho- 
rized to sell the content and/or identification of one or more 
electronic book digital rights management (DRM) systems. 
For security, the server 210 and publisher client 204 can 
communicate over a secure network connection, such as 
HTTPS (HyperText Transfer Protocol Secure), that 
encrypts/decrypts information communicated by the pub- 
lisher client 204 and the server 210. 

[0030] The server 210 can use the received content 230 
and metadata 232 to automatically generate distribution 
versions of the content. For example, for electronic distri- 
bution, the server 210 can automatically prepare a version of 
the content for distribution in accordance with the identified 
DRM scheme(s). Similarly, for hard copy printing, the 
server 210 can automatically generate a version of the 
content, for example, by preparing an image of each page to 
be printed. 

[0031] As shown in FIG. 4, the server 210 includes a 
content management 214 system that stores and processes 
the received content 230 and metadata 232. The server 210 
also includes a fulfillment system 220 that features instruc- 
tions for different digital rights management systems. For 
example, the fulfillment system 220 may support DRMs 
from non-affiliated vendors. For instance, the system 220 
may feature Microsoft Reader Digital Asset Server and 
Adobe Content Server Digital Rights Management System. 

[0032] As shown, the server 210 may also include web 
server instructions 212 that make these features available to 
a publisher 204 via an Internet web-site. In technical terms, 
the web server instructions 212 handle HTTP (HyperText 
Transfer Protocol) messages exchanged with network clients 
(e.g., web browsers). These messages can include, for 
example, instructions for presenting a user interface that 
transmits information collected from a remote user back to 
the server 210. Such user interface instructions may be 
encoded in a variety of ways such as SGML (Structured 
Generalized Markup Language) instructions (e.g., HTML 
(HyperText Markup Language) and XML (extensible 
Markup Language)) or instructions that include conditional 
statements (e.g., "IF" statements) such as an applet. 
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[0033] FIGS. 5-11 illustrate samples of user interface 
screens the server 210 may provide to a publisher to collect 
content and metadata. These sample screens depict stages of 
a sample process of content submission that includes select- 
ing one or more distribution options, providing information 
for the selected options, monitoring the processing status of 
submitted content, and proofing a distribution version of the 
content. The following sequence may be preceded, for 
example, by user interface screens that enable a publisher to 
set up an account. For instance, a publisher may provide 
banking or credit information for billing and/or compensa- 
tion. 

[0034] As shown in FIG. 5, after establishment of an 
account, content submission can permit user selection of 
hard copy "print -on-demand" preparation 262 and/or eBook 
distribution 264 of the content. As shown, a publisher 
selecting eBook distribution 264 may also select one or 
more DRM schemes for eBook distribution (e.g., "MS 
Reader Format"266 or "Adobe eBook Format"268). 

[0035] As shown in FIG. 6, a user interface screen may 
collect some metadata applicable to both eBooks and "print- 
on-demand" titles. For example, as shown, the user interface 
can collect a title 271, a publisher reference number 272 
such as an ISBN (International Standard Book Number), a 
language 273, a list of contributors 270, and a summary 
annotation 277. The user interface may also collect a pub- 
lication date 274 and/or a "street date" (the date the publi- 
cation may first be offered for sale) 276 that represents a date 
in the future before which the publisher does not want 
distribution to occur. 

[0036] As shown, the user interface also enables a pub- 
lisher to select a method of delivering content 278 to the 
server. For example, a publisher can select file upload over 
the Internet, physical delivery of a computer readable 
medium (e.g., a CD-ROM or floppy), or a hard copy for 
scanning or other conversion into electronic form. The 
publisher can similarly specify 279 a mechanism for upload- 
ing a book cover image. 

[0037] Other screens may collect other information from a 
publisher. For example, other screens may collect an edition 
number or description, an indication of whether the edition 
is an abridged edition, whether the content is "large print", 
a series ID and/or number, one or more subject matter 
categories, an audience age range or reading level, and one 
or more identification codes (e.g., a Library of Congress card 
number, a Dewey Decimal Classification No., a UPC [Uni- 
versal Product Code] code, and so forth). 

[0038] As shown in FIG. 7, a publisher can also specify 
both list prices and wholesale discounts. The server can use 
this information to automatically initiate transactions to 
compensate the publisher for each sale. The publisher may 
also specify territorial rights. For example, a publisher may 
not wish, or be permitted, to sell or transmit content beyond 
particular geographic bounds. 

[0039] The information collected from a publisher may 
differ depending on the distribution methods selected. For 
example, FIG. 8 shows additional information collected for 
eBook distribution. As shown, the user interface can enable 
a publisher to select different DRM options 284, 286 sup- 
ported by selected DRM systems. For example, Adobe 
Reader options 286 can give a publisher control over con- 
sumer printing and copying based on a maximum number of 
days or copies. 



[0040] The user interface shown in FIG. 8 also enables a 
publisher to rate 280 the complexity of the content. For 
instance, a novel with plain text may be less complex to 
convert to an eBook than a multi-column, graphic-intensive 
textbook. The rating scheme may be based on a number of 
criteria such as the number of columns of text, number of 
images or tables per page, number of hyperlinks per page, 
whether the content includes a table of contents, footnotes, 
and so forth. For example, a rating scheme may be defined 
as follows: 



Description 



Example 



Type 
1 



Type 
2 



Type 
3 



Type 
4 



Type 
5 



Single column text 

Limited line art, line charts, tables, 

and B&W images (no more than 1 per 15 

pages) 

Table of Contents hyperlinking 
Single column text 
Column based images, line art, line 
charts and tables (no more than 1 per 
4 pages) 

Content hyperlinking (up to 1 per 
page) 

Single column text 
Column based images, line art, line 
charts and tables (no more than .6 
per page) 

Intensive content hyperlinking 

(up to 3 links per page) 

Extensive and complex tables 

Indexes, bibliography, or footnotes 

Multicolumn text 

Heavy, repetitive formatting 

Heavy images, large image orientation 

Limited hyperlinking (less than 1 per 

page) 

Images, text or tables across spreads 

Flowing layouts with minimal 

repetitive formatting 

Highly illustrative 

Intensive content hyperlinking 

Media enhancement 



Novels 



Novels 



Technical, 
academic, and 
reference books 



Cooking, arts 
& crafts, 
coffee table 
books 



Instructional 
children and 
young adult 
books 



[0041] Based on the rating, the server may determine a fee 
for processing the content. Additionally, the server can use 
the rating to determine whether a requested format may be 
a poor selection. For example, Adobe PDF format provides 
a fixed page layout regardless of display device and may not 
be appropriate for material having many columns. 

[0042] As shown in FIG. 9, information collected for 
content selected for "print-on-demand" may differ from that 
collected for eBook distribution. For example, as shown, the 
user interface may collect user input specifying a type of 
binding 288 and/or the text 290 to print on the book spine. 
[0043] Again, after receiving the metadata entered by the 
publisher and the content, the server can automatically 
prepare the content for distribution in the publisher selected 
format(s). After doing so, the server may generate one or 
more "proofing" copies of the distribution version(s) of the 
content. For example, the server may prepare and transmit 
an eBook to the publisher or, in the case of "print-on- 
demand" content, the server may prepare an Adobe PDF 
(Portable Document Format) file featuring images of the 
pages as they would be printed. In either case, as shown in 
FIG. 10, a publisher can accept 292 or reject 294 the 
proofing copy by interaction with the user interface. 
Accepted proofs will be made available for distribution. 
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[0044] As shown in FIG. 11, a publisher can monitor 
progress of their submitted titles throughout the content 
submission process. For example, the user interface shown 
indicates the status of each submitted title. Such statuses 
include "awaiting material", "pre-flighting", and "proofing". 
Additionally, selecting a title hyperlink can cause display of 
more detailed information about the title, such as its corre- 
sponding metadata. 

[0045] FIG. 12 shows a process 240 for automatic han- 
dling of content submission. As shown, the process 240 may 
begin with receipt 241 of content and its corresponding 
metadata. The process 240 can handle a wide variety of 
content formats such as Adobe Acrobat PDF, PostScript, 
QuarkXpress, PageMaker, InDesign, Word, and tagged text 
formats such as HTML. Many of these content formats do 
not include conditional statements. 

[0046] As shown, the process 240 may validate 243 
received metadata. For example, the process 240 may ensure 
that no metadata specifies a wholesale discount over %50. 
The process 240 may also validate an ISBN number, for 
example, by verifying the number's check digit. A wide 
number of other metadata validations may take place such as 
a request of payment authorization from a publisher's credit 
source. 

[0047] After receipt 241 of the content and metadata, the 
process 240 automatically checks ("pre-flights") the content 
for numerous issues which might prevent accurate automatic 
preparation of a title. For example, the process 240 may 
verify receipt of all image files and required fonts. Should an 
error be encountered, the server can automatically notify the 
publisher and await resubmission. 

[0048] Assuming the metadata validation 243 and pre- 
flighting proceeded without significant error, the process 240 
can continue converting the received content to a selected 
distribution format(s), for example, by reflowing and rep- 
aginating text, replacing images, and so forth. 

[0049] If the selected distribution format(s) include hard 
copy distribution 245, the process 240 can automatically 
perform a number of tasks that prepare the content for 
printing. For example, for text submissions, the process 240 
can parse the content to construct 247 a table of contents. 
The process 240 can also perform a wide variety of other 
tasks such as analyzing the structure of text to indent the first 
paragraph of a new chapter more than other paragraphs. 
Similarly, the process 240 may alter text, for example, by 
compressing three consecutive periods into a single ellipses 
character or using an elongated dash instead of using a 
simple "-" character. The process 240 may also perform 
other tasks, such as extracting a cover image from the 
content. 

[0050] As shown, the process 240 can calculate 249 a 
spine width for a manufactured book based on page thick- 
ness and the number of pages. The process 240 can also 
determine a spine image for the binding, for example, by 
creating an image of the title in a font that fits the spine 
width. 

[0051] After automatically generating information for 
printing the content, the process 240 can generate 250 a 
proof copy, for example, by e-m ailing images of the pages 
to be printed or by sending a hard copy of the title for 
publisher review. After review, the process 240 can send 251 



the generated information for the title to a manufacturing 
engine that can control printing of the title on demand, for 
example, by printing a color cover, printing a book block, 
and binding the printed cover and book block. 

[0052] A different sequence may occur if the selected 
distribution format(s) include electronic book distribution 
253. For example, the process 240 may process the content 
to generate 255 one or more Open eBook (OEB) files. For 
instance, the process 240 may include extraction of a cover 
page from submitted content and/or lossy compression of 
submitted images to reduce the size of any distribution files. 

[0053] Based on these OEB files, the process 240 may 
generate 257 DRM specific files. Generation of DRM spe- 
cific files may include DRM specific conversions. For 
example, for an Adobe eBook, generation may include 
construction of an Adobe style hyperlinked table of contents, 
a copyright page updated to include eBook ISBN, and 
logical page numbers that permit eBook pages to match a 
title page numbering sequence. For a Microsoft eBook, 
generation may include construction of a Microsoft style 
floating hyperlinked table of contents, a copyright page 
updated to include eBook ISBN, and conversion of non- 
supported book layouts (e.g., marginal notes, floating art, 
cross spread images or boxes, conversion of footnotes to 
endnotes, placement of footnote as display text, and place- 
ment of images or graphics close to, but not preceding, the 
callout). Additional advanced features may also be available 
at the option of the publisher. These can include linked index 
entries, removal of blank pages, cross-referencing, contex- 
tual links, listings of figures and tables, and links from text 
reference of a figure to the figure or a footnote text reference 
to an endnote. After proofing 259, the completed DRM 
specific file is posted 261 to a DRM Engine (described 
below) for subsequent distribution. 

[0054] As shown, after generation of a title in the selected 
distribution format(s), the process 240 may store 260 the 
title's metadata in a database of metadata corresponding to 
different titles. As described below, this stored metadata can 
be used to construct a catalog of titles for a retailer. 

[0055] III. Catalogs 

[0056] Retailers often play an important role in publica- 
tion sales, for example, by handling the tasks of promoting 
publications. For instance, Amazon.com promotes most of 
its available publications with a web-page providing a cover 
image, summary, and reader reviews. Some retailers provide 
libraries of over one million titles making the maintenance 
of their offerings a potentially time consuming task. 

[0057] As shown in FIG. 13, a server 210 can include 
catalog generation and distribution instructions 218 that can 
generate a "catalog"300 of titles a retailer is authorized to 
sell. The catalog 300 can list titles available to a retailer and 
can include some or all of the metadata submitted with a 
title. Additionally, the catalog generation instructions 218 
can customize the format of the catalog 300 for a particular 
retailer 206, for example, to work with software the retailer 
may use to manage title information. For instance, the 
retailer 206 may feature software that automatically pro- 
cesses a received catalog 300 to create new web -page 
information for new titles or amend web-page information 
for pre-existing ones. 
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[0058] FIG. 14 illustrates an example of catalog 300 
generation. As shown, a process 308 selects catalog 300 data 
from stored metadata records 310. The metadata records 310 
correspond to submitted titles and can include information 
identifying one or more authorized retailers and/or one or 
more unauthorized retailers. The process 308 can use the 
information to select metadata records of titles a particular 
retailer is authorized to handle. 

[0059] For example, metadata records 302 and 306 des- 
ignate "Amazon" as an authorized retailer for eBooks of 
John Grisham's "The Firm"302 and "The Chamber**306. 
Thus, the catalog 300 generated by the process 308 can 
include records for these titles, for example, as a result of an 
SQL (Structured Query Language) query for records listing 
"Amazon" as an authorized retailer. 

[0060] While the metadata records shown specify indi- 
vidual retailers, a publisher may identify a group of retailers 
by attributes or a grouping code (e.g., "E-Commerce Ven- 
dors"). Additionally, a default set of retailers may apply to 
metadata records that do not specify a particular set of 
retailers. 

[0061] Since different retailers may use different software 
and/or data formats to process title records, the process 308 
can customize the catalog 300 file generated for a particular 
retailer by using customized formatting information 312. 
Such formatting information 312 can specify the metadata to 
include in the catalog 300 and the arrangement and encoding 
of included metadata. For example, as shown, the catalog 
310 features a semi-colon delimited record for each title. 
That is, a semi-colon separates different fields of the record. 
Alternatively, catalog 300 records can be encoded in a 
markup language for easy incorporation into a retailer's 
web-pages. For example, a record of "<TITLE>The Firm</ 
TITLE><AUTHOR>Grisham</AUTHOR>" includes 
<TTTLE> and <AUTHOR> markup tags that identify the 
information included in the record. 

[0062] In addition to text and other data, a retailer may 
also prefer to receive an image of a book cover for display 
by their web-pages. Such images may be included as data 
within a catalog, for example, as JPEG (Joint Picture 
Experts Group) or GIF (Graphics Interchange Format) 
image data. Alternatively, each title may have corresponding 
images stored at a FTP (File Transfer Protocol) site in 
accordance with a naming convention such as title_xpixel- 
size_x_ypixelsize.format (e.g., The Firm _600_x_ 
400.jpeg). 

[0063] FIG. 15 illustrates an example of a process 330 that 
the catalog generation instructions 218 may implement. As 
shown, the process 330 selects 302 metadata records of titles 
for inclusion in a retailer's catalog. The selection 302 can 
feature both "authorization filters" that restrict retailers to 
titles they are authorized to sell and "retailer defined filters" 
that prevent retailers from including in a catalog works they 
are not interested in selling or promoting. 

[0064] The authorization filters can test for a variety of 
conditions that may prevent inclusion of a work in a retail- 
er's catalog. For example, the filters may eliminate a work 
from a catalog if the retailer is outside the territory in which 
the work is authorized to be sold. Similarly, the filters may 
eliminate a title from inclusion in a catalog if the title has not 
yet been priced for sale or if the work has not yet been 
proofed by the publisher. 



[0065] The "retailer defined filters" enable a retailer to 
specify characteristics of works that the retailer does not 
want to sell or promote. For instance, "Bob's Sci-Fi eBook 
Store" may only be interested in publications categorized as 
science or science fiction. Thus, in this example, the process 
330 may check to limit titles included in a Bob's catalog to 
only include titles in these categories. Similarly, a retailer, 
for example, may request only those titles approved by some 
organization. 

[0066] As described above, information for titles selected 
for inclusion in the catalog may be formatted 334 according 
to retailer preference. After completing the selection 332 and 
formatting 334, the catalog may be transmitted 336 to the 
retailer. Transmission may occur, for example, via e-mail or 
a sequence of HTTP messages. Transmission may alterna- 
tively occur by storing the catalog in an FTP (File Transfer 
Protocol) directory accessible by the retailer. This latter 
option enables the retailer to control when and how often the 
catalog information is received. 

[0067] The process 330 shown in FIG. 15 may be pro- 
grammed to automatically repeat at a designated interval. 
For example, a retailer may request automatic generation of 
a catalog on a daily or weekly basis. For retailers receiving 
more than one catalog at different times, the process 330 
may generate "delta" catalog files that only include changes 
from a preceding catalog. For example, the catalog may only 
include new titles authorized for sale by a retailer or new/ 
changed information about titles in a previous catalog or 
catalogs. 

[0068] IV Fulfillment 

[0069] A server 210 may provide a web-site that enables 
consumers and/or publishers to request electronic books or 
"print-on-demand" hard copies of a title. However, as 
described above, retailers often handle the task of presenting 
titles to consumers for purchase. For example, Amazon.com 
allows consumers to search lists and descriptions of different 
available eBooks. In the case of eBooks, fulfilling purchase 
requests can add the burden of DRM system maintenance 
and support to a retailers responsibilities. FIGS. 16-18 
illustrate a system that can remove the burden of handling 
these fulfillment duties from a retailer. 

[0070] As shown in FIG. 16, a consumer 208 can interact 
with a retailer 206 over a network 202 through mechanisms 
selected by the retailer 206 such as web-pages, email, and so 
forth. After a consumer 208 requests 322 an eBook title, for 
example, by selecting a title from a web-page 320, a 
fulfillment process 220 provided by a remote server 210 
handles distribution of the eBook to the consumer. The 
server 210 may be the same server 210 providing other 
features described herein. 

[0071] As shown in FIG. 17, the retailer 206 transmits 
fulfillment information 324, such as a URL (Universal 
Resource Locator) link, to the consumer 208 for each 
purchased eBook. For example, the retailer 206 may include 
the URL in an e-mail message sent to the consumer 208 or 
may include the URL in a dynamically constructed web- 
page that lists items requested by a consumer 208. 

[0072] When activated, the link directs a secure message 
326 to the server 210. The message 326 encodes identifica- 
tion of the title ordered and identification of the retailer. For 
example, a consumer may receive a URL having the fol- 
lowing format: 

https^/sc rve r.com ?paramctcrs-rctai!er I D&itcm I D 
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[0073] where "hups" identifies a secure connection 
between the consumer 208 and server 210, "server.com" 
identifies the location of the server 210 in the network, and 
retailerlD and item ID identify the retailer and ordered item 
SKU (Store Keeping Unit, the product identifying number 
used by the server 210), respectively. The URL parameters 
may be encrypted, for example, using Triple DES. Addi- 
tionally, the URL may feature additional parameters such as 
a time stamp and/or the results of a hashing of the other 
parameters to thwart pirate attempts to construct a valid 
URL. The URL may also include a tracking number 
assigned by the retailer to the transaction for retailer tracking 
purposes. As the server 210 may insulate the retailer 206 
from DRM tasks, the URL need not include identification of 
any particular DRM system. 

[0074] As shown in FIG. 17, when the consumer selects 
the URL link, the consumer's 208 client no longer needs to 
interact with the retailer 206, but is instead interacting with 
the server 210. However, this may be completely transparent 
to a consumer 208. That is, the consumer 208 may only 
perceive interaction with the retailer 206. To enhance this 
effect, the server 210 may provide user interfaces custom- 
ized for a particular retailer. For example, a server 210 may 
provide status and error message web-pages that promi- 
nently feature the retailer's logo, stylesheet, or other infor- 
mation for each retailer using the server 210 

[0075] As shown in FIG. 18, after receiving the eBook 
request, the server 210 handles distribution 332 of the eBook 
to the consumer in accordance with the digital rights man- 
agement system associated with the title. After distribution 
332, the server 212 can transmit confirmation 333 to the 
Retailer 206 describing both successful delivery of the 
content or, in the event of a failure, what the reason for 
failure. 

[0076] As shown, the server 210 supports multiple DRM 
systems. While each DRM system may operate differently, 
many share a similar sequence. In a typical scenario, DRM 
distribution of a title begins when a DRM system attempts 
to connect to the consumer's 208 reader software. If the 
reader software is not installed, the system can guide the 
consumer through a download/installation process. The 
DRM system then requests credentials (e.g. computer ID, 
reader software ID) and uses these credentials to "lock" a 
copy of the ordered title for that consumer. Such locking 
may occur by encrypting a copy of the title or providing an 
encrypted voucher needed by the reader software to open a 
genetically encrypted copy of the title. A "locked" copy of 
the title is then sent to the consumer 208. The consumer's 
208 device then automatically launches the reader software 
associated with the DRM scheme used and loads and 
presents the title. While the process described above may 
seem complex, the entire process happens in real-time and, 
typically, does not take more time than loading a standard 
web page. 

[0077] The scheme described above can offer a number of 
potential benefits. Again, by server 210 handling fulfillment, 
retailers need not be aware that DRMs are even being used. 
Additionally, while FIGS. 16-18 illustrate distribution of a 
title for a single retailer 206, the server 210 can support 
many different retailers and their consumers simultaneously. 
Thus, addition of a new DRM system at the server 210 can 
expand the number and variety of product distribution 
capabilities of many retailers. 



[0078] The server 210 may implement DRM handling by 
bundling instructions for different DRM systems into a 
DRM Processing Engine. The server 210 may include many 
different DRM Processing Engines operating in parallel. 
This technique can permit load balancing between the DRM 
Processing Engines and provide scalability as the number of 
fulfillment operations increases. Additionally, new DRM 
Processing Engines can be added or removed at any time 
without impacting system availability. 

[0079] FIG. 19 illustrates a title fulfillment process 350. 
As shown, the process 350 receives a request for a title 352. 
The process 350 may then verify security information (e.g., 
a hash value) received with the request. This may trigger 
transmission of a confirmation message (e.g., an HTTP 
message) to the retailer. This provides retailers with virtually 
real-time confirmation of consumer use of the order link 
supplied by the retailer 206. These confirmation messages 
may be queued for retransmission when a retailer's 206 
web-site is down. The confirmation message may include 
identification of the ordered title and/or order number, 
among other information. 

[0080] As shown in FIG. 19, the process 350 may deter- 
mine 354 whether to distribute the electronic book to the 
network client in accordance with one or more business 
rules applied 354 independent of DRM operation. For 
example, a business rule may verify that the retailer iden- 
tified in the request is authorized to sell the title. A different 
business rule may deny access to a title before a street date 
specified by the publisher. Yet another business rule may 
verify that the consumer is not downloading the book to 
different devices or exceeding a maximum number of down- 
loads. As new requirements emerge, business rules may be 
created and/or updated. The business rules may be encoded, 
for example, as boolean expressions or in a programming 
language such as C and/or SQL (Structured Query Lan- 
guage). If a business rule indicates distribution should not 
occur 358, the process 350 can transmit 360 corresponding 
error messages and/or customized screens to the retailer 
and/or consumer. 

[0081] After business rule application, the process 350 
may determine 362 a DRM system selected for the title. For 
example, server instructions may use the received retailer ID 
and the title ID of the request to perform a table lookup of 
DRM systems associated with the title by the retailer. 
Thereafter, the title can be distributed 364 in accordance 
with the determined DRM. As specified by a DRM or 
business rule, successful downloading of titles may be noted 
to prevent the consumer from re -downloading the same 
eBook using the original URL link. Failed downloads may 
not be recorded to enable a consumer to attempt to re- 
download in the event of a bad Internet connection. 

[0082] As shown, the process 350 may log 366 informa- 
tion describing a transaction, for example, by logging infor- 
mation used in billing, determining publisher compensation, 
business rule audits, determining DRM usage fees, and so 
forth. 

[0083] Again, throughout the process 350 illustrated in 
FIG. 19, retailers and/or consumers may receive status and 
error messages regarding the progress of their request. 
Examples of events that can cause notification include the 
occurrence of unknown errors, completion of a successful 
download, a determination that a title was not found or 
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available, a determination that the consumer did not order 
the title from an authorized retailer, a determination that the 
download attempt exceeded a limit, the occurrence of com- 
munication errors, a determination that reader software was 
not installed or activated, and a determination that the 
received consumer credentials were incorrect. While the 
server may offer a predefined set of status and error message 
web pages, these messages may be customize in real-time to 
each retailer's specifications. Alternatively, events can trig- 
ger a re-direct to a web-page provided by the retailer's 
web-server. 

[0084] Again, the process 350 may provide retailers with 
status information such as confirmation of an order. For 
example, a server may transmit a confirmation message to a 
retailer that encrypts the order tracking number, time stamp, 
and other information. 

[0085] V. Implementations 

[0086] The techniques described herein are not limited to 
any particular hardware or software configuration; they may 
find applicability in any computing or processing environ- 
ment. The techniques may be implemented in hardware or 
software, or a combination of the two. Preferably, the 
techniques are implemented in computer programs execut- 
ing on programmable computers that each include a proces- 
sor, a storage medium readable by the processor (including 
volatile and non-volatile memory and/or storage elements), 
at least one input device, and one or more output devices. 

[0087] Each program is preferably implemented in high 
level procedural or object oriented programming language to 
communicate with a computer system. However, the pro- 
grams can be implemented in assembly or machine lan- 
guage, if desired. In any case the language may be compiled 
or interpreted language. 

[0088] Each such computer program is preferably stored 
on a storage medium or device (e.g., CD-ROM, hard disk, 
or magnetic disk) that is readable by a general or special 
purpose programmable computer for configuring and oper- 
ating the computer when the storage medium or device is 
read by the computer to perform the procedures described 
herein. The system may also be considered to be imple- 
mented as a computer-readable storage medium, configured 
with a computer program, where the storage medium so 
configured causes a computer to operate in a specific and 
predefined manner. 

[0089] Other embodiments are within the scope of the 
following claims. 



What is claimed is: 

1. A method of distributing electronic books over a 
computer network, the method comprising: 

transmitting user interface instructions to a publisher's 
network client in response to an HTTP (HyperText 
Transfer Protocol) request received from the client, the 
user interface instructions providing a web -page form 
that enables the publisher to identify electronic content 
and corresponding metadata, the metadata including 
designation of at least one electronic book digital rights 
management system from at least two supported digital 
rights management schemes from different unaffiliated 
vendors, the metadata also including hard printing 
information; 

receiving the identified electronic content and metadata 
from the network client; 

automatically generating an electronic book from the 
received electronic content corresponding to the iden- 
tified electronic book digital rights management sys- 
tem; 

storing the metadata with metadata associated with other 
received electronic content; 

selecting metadata from the stored metadata, the selected 
metadata corresponding to electronic content autho- 
rized for a retailer; 

storing at least a portion of the selected metadata for 
transmission to the retailer over the network in accor- 
dance with formatting information received from the 
retailer; 

receiving a request for the electronic book from a network 
client in response to a user's selection of the corre- 
sponding electronic content from a user interface pro- 
vided by the retailer, the request including an electronic 
book identifier and a retailer identifier, the request 
being a URL (Universal Resource Locator) that 
encodes the electronic book identifier and the retailer 
identifier as one or more URL parameters; 

determining whether to distribute the electronic book to 
the network client by applying one or more business 
rules to the request; and 

distributing the electronic book to the network client in 
accordance with the electronic book's electronic book 
digital rights management system. 

***** 
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